Skip to content

Conversation

kernel-patches-daemon-bpf[bot]
Copy link

Pull request for series with
subject: Add a dynptr type for skb metadata for TC BPF
version: 7
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: 0786654
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429
version: 7

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: dc0fe95
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429
version: 7

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: c80d797
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429
version: 7

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: 3ec8560
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429
version: 7

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: 1274163
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429
version: 7

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: d87fdb1
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429
version: 7

Add a dynptr type, similar to skb dynptr, but for the skb metadata access.

The dynptr provides an alternative to __sk_buff->data_meta for accessing
the custom metadata area allocated using the bpf_xdp_adjust_meta() helper.

More importantly, it abstracts away the fact where the storage for the
custom metadata lives, which opens up the way to persist the metadata by
relocating it as the skb travels through the network stack layers.

Writes to skb metadata invalidate any existing skb payload and metadata
slices. While this is more restrictive that needed at the moment, it leaves
the door open to reallocating the metadata on writes, and should be only a
minor inconvenience to the users.

Only the program types which can access __sk_buff->data_meta today are
allowed to create a dynptr for skb metadata at the moment. We need to
modify the network stack to persist the metadata across layers before
opening up access to other BPF hooks.

Once more BPF hooks gain access to skb_meta dynptr, we will also need to
add a read-only variant of the helper similar to
bpf_dynptr_from_skb_rdonly.

skb_meta dynptr ops are stubbed out and implemented by subsequent changes.

Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Sitnicki <[email protected]>
Now that we can create a dynptr to skb metadata, make reads to the metadata
area possible with bpf_dynptr_read() or through a bpf_dynptr_slice(), and
make writes to the metadata area possible with bpf_dynptr_write() or
through a bpf_dynptr_slice_rdwr().

Note that for cloned skbs which share data with the original, we limit the
skb metadata dynptr to be read-only since we don't unclone on a
bpf_dynptr_write to metadata.

Signed-off-by: Jakub Sitnicki <[email protected]>
dynptr for skb metadata behaves the same way as the dynptr for skb data
with one exception - writes to skb_meta dynptr don't invalidate existing
skb and skb_meta slices.

Duplicate those the skb dynptr tests which we can, since
bpf_dynptr_from_skb_meta kfunc can be called only from TC BPF, to cover the
skb_meta dynptr verifier checks.

Also add a couple of new tests (skb_data_valid_*) to ensure we don't
invalidate the slices in the mentioned case, which are specific to skb_meta
dynptr.

Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Sitnicki <[email protected]>
@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: dbe99ea
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429
version: 7

Prepare for parametrizing the xdp_context tests. The assert_test_result
helper doesn't need the whole skeleton. Pass just what it needs.

Acked-by: Eduard Zingerman <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Sitnicki <[email protected]>
We want to add more test cases to cover different ways to access the
metadata area. Prepare for it. Pull up the skeleton management.

Acked-by: Eduard Zingerman <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Sitnicki <[email protected]>
Exercise reading from SKB metadata area in two new ways:
1. indirectly, with bpf_dynptr_read(), and
2. directly, with bpf_dynptr_slice().

Acked-by: Eduard Zingerman <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Sitnicki <[email protected]>
Add tests what exercise writes to skb metadata in two ways:
1. indirectly, using bpf_dynptr_write helper,
2. directly, using a read-write dynptr slice.

Acked-by: Eduard Zingerman <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Sitnicki <[email protected]>
Exercise r/w access to skb metadata through an offset-adjusted dynptr,
read/write helper with an offset argument, and a slice starting at an
offset.

Also check for the expected errors when the offset is out of bounds.

Acked-by: Eduard Zingerman <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Sitnicki <[email protected]>
Demonstrate that, when processing an skb clone, the metadata gets truncated
if the program contains a direct write to either the payload or the
metadata, due to an implicit unclone in the prologue, and otherwise the
dynptr to the metadata is limited to being read-only.

Signed-off-by: Jakub Sitnicki <[email protected]>
@kernel-patches-daemon-bpf
Copy link
Author

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=991429 irrelevant now. Closing PR.

@kernel-patches-daemon-bpf kernel-patches-daemon-bpf bot deleted the series/991429=>bpf-next branch August 18, 2025 20:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant